home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Collection of Tools & Utilities
/
Collection of Tools and Utilities.iso
/
dskut
/
ramit166.zip
/
RAMIT.DOC
< prev
next >
Wrap
Text File
|
1990-05-09
|
31KB
|
961 lines
+-------------+
| RAMIT!!! |
+-------------+
If you're running an 8-bit hard disk controller (generally
designed for both PCs and ATs) on a 16 bit machine (like an
AT or AT&T PC6300) then RAMIT! may be able to help you
improve your disk transfer speed.
What is RAMIT?
RAMIT is a program to run the disk
code supplied with an PC type disk
controller out of RAM rather than
from the disk controller's ROM.
What does that do?
By running out of RAM rather than
ROM, some machines can achieve a
real performance gain in disk
transfer time.
Does this apply to
me?
RAMIT can make a difference in a
number of situations. To see any
disk performance improvement,
1. You must be using a hard disk
controller which has its own BIOS
ROM code. This includes unmodified
Western Digital, Mountain, Perstor
and Plus [Hardcard] controllers.
Undoubtedly there are many others.
2. You must have a machine which
runs code faster from RAM than the
I/O bus. This includes all 16 bits
machines (AT types) and many other
compatibles (e.g. AT&T PC6300).
3. You must be willing to reformat
your hard disk to get the benefit
of this speedup. Naturally, this
requires a full backup and restore.
Still Interested?
Read on.
RAMIT! Copyright (c) Hanover Systems, 1987, 1988
+-----------------------------------+
| OK, so what does RAMIT! do!!!! |
+-----------------------------------+
RAMIT! is a TSR which relocates your disk controller ROM into
high-speed RAM and 'fixes up' MSDOS to run the disk code from
RAM.
RAMIT! operates as follows:
1. RAMIT! verifies that there is a valid ROM BIOS at
C800:0000.
2. RAMIT! copies the disk ROM contents to RAM.
3. RAMIT! disassembles the ROM to find out what it had
placed in vector locations 4C and 64. These are the primary
entry points into the ROM code. If RAMIT! is unable to
determine these values, then it aborts with an error
message. This is generally attributable to an unusual
instruction sequence used to 'steal' the vectors. Contact
the author for unusual ROMs.
If you'd rather do the disassembly yourself, the original 4C
and 64 vector addresses can be specified on the command
line. This is the dirty way to support controllers whose
initialization sequence is simply too messy for automatic
decoding.
If RAMIT! 'knows' about your ROMs, it knows which 4C, 64 and
edit parameters to use. RAMIT calculates a CRC for the
resident portion of a ROM and scans an internal table. If
your ROM is not in the table, contact the author and supply
a floppy disk with the ROM on it.
4. RAMIT! 'fixes' MSDOS or PCDOS by finding where DOS keeps
the vector originally placed by the disk ROM BIOS and
redirecting it to the RAM copy.
5. RAMIT! exits, leaving only a copy of the vendor's ROM
code. All RAMIT! code is removed. Most unused ROM code is
also removed. The amount of memory taken depends on the
size and complexity of the disk controller ROM BIOS. In no
event will it be more than 8K of code.
RAMIT! Copyright (c) Hanover Systems, 1987, 1988
+----------------------------+
| Well how do I run RAMIT? |
+----------------------------+
Find out your current performance level
Before seeing whether RAMIT! can make a difference, you must
know how your system performs before RAMIT! is installed.
If your disk/PC combination is not explicitly mentioned in
the README.RAM file in this archive (and you can't find
another PC close enough), then you may have to experiment to
find the best interleave factor.
SPINTEST is a publicly available utility which computes disk
transfer rate. It can be used to see when the optimum
interleave has been established.
Another program, ATDISK, often distributed as part of the PC
Tech Journal utilities will calculate the transfer rate.
Finally, the CORETEST program from Core International will
compute the transfer rate. Any of these programs can be
used to determine when the optimum interleave has been
found.
First, run SPINTEST to get the transfer rate and interleave.
Then reduce the interleave until you suddenly see a
reduction in the transfer rate. At that point you've gone
too far! Back off by increasing the interleave slightly and
reformat for the last time.
MAKE SURE THAT YOU'VE INSTALLED RAMIT BEFORE RUNNING ANY
PERFORMANCE TEST. IF YOU HAVEN'T YOU'RE JUST MEASURING THE
PLAIN VANILLA PERFORMANCE OF YOUR CONTROLLER ROM-BASED
SOFTWARE!!!
The following may serve as an example:
Set IL=6; Spintest says 6 revolutions to read a track.
Set IL=5; Spintest says 5 revolutions to read a track.
Set IL=4; Spintest says 4 revolutions to read a track.
Set IL=3; Spintest says 18 revolutions to read a track.
At this point, going to an interleave of 3 does more
harm than good. Back off and use an interleave of 4.
An easier way is to install RAMIT and use one of several
programs which promise to determine the optimum interleave.
RAMIT! Copyright (c) Hanover Systems, 1987, 1988
ILEAVE19.ARC (a public domain program) and Gibson Research's
SPINRITE (definitely not in the public domain) are two such
programs. Please note that it is critical to install RAMIT!
before running these test programs otherwise, you'll be
getting the best value without RAMIT!.
Testing RAMIT! the first time
At first, RAMIT! should be run in TEST mode. This will
indicate whether RAMIT! is likely to work on your machine.
Type
RAMIT /T
and examine the output. There should be three messages
indicating that 0000:xxxx has been overwritten. Don't
worry, in TEST mode the memory is not actually modified.
If RAMIT! fails or the messages don't appear, check the
README.RAM file in this archive. If your drive and computer
isn't on the list, be careful. Things may very well not
work.
If you get no error messages, RAMIT! will probably work for
you.
The following is a sample installation using the /V option.
(Specifying /T assumes /V.)
> RAMIT /V
RAMIT! [V1.6] Copyright (c) 1988 Hanover Systems.
All rights reserved. ] Version
Disk controller vector 1B at C800:0A79 moved to segment
0DB2
Overriding segment address at 0000:1ECB + Expect 2
Overriding segment address at 0000:2